Problem

The maintainer-approval.js script (run by the "PR approval" workflow) creates the required maintainer-approval status check on the PR head SHA when approval is satisfied:

await github.rest.checks.create({ ...checkParams, conclusion: "success", ... });

There is no verification that this write actually took effect. When checks.create returns 2xx but the check does not register on the head commit (GitHub eventual consistency), the workflow run still exits green while the required maintainer-approval status stays stuck as "Expected" in the UI. Because the pending path deliberately posts no check at all, nothing re-establishes it — the PR is silently blocked from the merge queue even though a maintainer approved, until some unrelated event happens to re-run the workflow.

This was observed on #5868: the "PR approval" run passed, a maintainer had approved, yet maintainer-approval remained "Expected" and the PR would not enter the merge queue.

Fix

Route all three success paths through a new createApprovalCheck helper that:

1. Creates the success check.
2. Re-reads the check on the head SHA via checks.listForRef to confirm it is visible.
3. Retries up to 3 times (with a short backoff) if it has not registered.
4. Calls core.setFailed if the check never lands, so the run goes red with an actionable message ("re-run this workflow to unblock the merge") instead of green-but-blocking.

A red, re-runnable check is far easier to notice and recover from than a silently stuck "Expected" status.

Tests

The test mock now models create → persist → read, with a flakyCreates knob to simulate non-persisting writes. Two new cases:

• retries when the first write does not persist — second create lands, no failure.
• fails when the check never persists — exhausts attempts and records setFailed.

The retry backoff is overridable via MAINTAINER_APPROVAL_VERIFY_DELAY_MS (set to 0 in tests). All 24 tests pass.

This pull request and its description were written by Isaac, an AI coding agent.